10分でわかる！Key Management Serviceの仕組み #cmdevio
こんにちは、虎塚です。
先日のCM re:Growth Developers.IO Meetup 11 Tokyo で「10分でわかるKey Management Serviceの仕組み」という発表をしました。今日は、イベントに参加されなかった方がご覧になっても内容が伝わるように、発表内容を記事に起こしてみました。
はじめに
Key Management Service（KMS）は、先月開催されたre:Invent 2014で発表された新サービスです。すでに全リージョンで利用できます。このサービスを使うと、データの暗号化/復号用の鍵をAWS上で管理できます。
ところで、KMSのAPIドキュメントを流し読みすると、マスターキーとデータキーという言葉が出てきます。そうです、KMSが扱う鍵は2種類あるんですね。
2つの鍵の違いは何か？ どう使い分けるのか？ などが、ぱっと見ではわかりづらいかもしれません。今回の発表では、このあたりを解説しました。
マスターキーとデータキーの特徴
マスターキーとデータキーの違いは、次のようになります。
後ほど徐々に意味が理解できればと思いますので、この時点ではさらっと眺めておいてください。
一般的なデータと暗号化の話
一般的な話から考えてみましょう。まず、保護したい大事なデータがある時、私たちはデータを暗号化することを考えます。
すると、暗号化に使った鍵の保管場所が問題になります。暗号化したデータは単独で盗まれても問題ありませんが、鍵と一緒に盗まれると復号されてしまうからです。
次に、私たちは鍵を暗号化することを考えます。別の鍵（鍵の鍵）をもう1つ用意して、データの暗号化に使った鍵を暗号化するわけですね。
すると、今度は"鍵の鍵"の保管場所が問題になります。暗号化したデータや暗号化した鍵は盗まれても問題ありませんが、鍵の鍵と一緒に盗まれると復号されてしまうからです。
これでは問題が解決していません！
解決策は、鍵の鍵をどこか安全な場所に保管することです。この「安全な場所」がAWSです。
"鍵の鍵"がマスターキー、データを暗号化した鍵がデータキーです。これがKMSの基本的な考え方です。
マスターキーとデータキーの特徴（再掲）
先ほどの比較表を見てみましょう。
マスターキーはデータキーを暗号化するための鍵で、データキーがデータを暗号化するための鍵であることが、ご理解いただけたかと思います。
KMSの機能（概要）
マスターキーとデータキーの関係性が理解できたところで、それぞれの鍵に対してできる操作を見ていきましょう。
マスターキーの管理
マスターキーを管理するための操作は、大きく分けると、作成、更新、無効化、有効化です。
なお、KMSでは、鍵の削除はサポートしていません。マスターキーを削除すると、マスターキーで暗号化したデータキーで暗号化したデータ（ややこしいですね）を復号できなくなってしまうためです。
具体的なAPIは、次のようになります。
更新系の操作がたくさん用意されています。よく使うAPIについては、後ほど1つずつ説明します。
データキーの利用
一方、データキーに対して可能な操作は、大きく分けると生成、データキーの暗号化、データキーの複合の3種類です。
具体的なAPIは、次のようになります。
よく使うAPIについては、後ほど1つずつ説明します。ちなみに、データキーでデータを暗号化/復号する操作は、AWSとの通信を必要とせずにローカルで行う操作なので、上の図には含んでいません。以下の説明には登場します。
KMSの機能（詳細）
マスターキーの作成（CreateKey）
マスターキーの作成は、APIのCreateKeyを利用します。API実行の流れは次のようになります。
作成時に、マスターキーのキーIDが返却されます。マスターキーがAWS側に保存される点と、マスターキー自体はユーザに返却されない点がポイントです。マスターキーは、AWSからローカルにエクスポートできません。
データキーの生成（GenerateDataKey）
データキーの生成は、APIのGenerateDataKey（もしくはGenerateDataKeyWithoutPlaintext）を利用します。API実行の流れは次のようになります。
この時、データキーの暗号化に使用するマスターキーのIDを指定する必要があります。後でデータキーを復号する際に、同じキーIDを指定する必要があります。
AWSの主張を信じるならば、AWS側ではマスターキーからデータキーを生成するためのロジックを保持していますが、データキー自体は保存しません。
ユーザには、暗号化されたデータキーと、暗号化されていないデータキーが返却されます。
データの暗号化＠ローカル
データキーの生成によって手に入れた暗号化されていない鍵を使って、データを暗号化します。この操作では、AWSのAPIは利用せず、AWSとの通信を行いません。
ここでは、データキーを暗号化に使い終わったら、ユーザの責任で即座に捨てることが非常に重要です。いくらAWSのセキュリティが強固でも、これを怠るとデータの安全性は損なわれます。
「そこは運用でカバーなの？」とがっかりするかもしれませんが、逆の見方をすると、ユーザが責任を持って行うべき作業を、KMSではこの部分に局所化してくれたといえます。
データキーの生成によって手に入れた、暗号化された鍵を大事に保管しておくことも重要です。この鍵を紛失してしまうと、暗号化したデータを二度と復元できなくなります。
データキーの復号
マスターキーのIDと、大事に保管していた暗号化されたデータキーを利用して、データキーを復号します。API実行の流れは次のようになります。
実行時には、データキーを生成する際に指定したマスターキーと、同じキーIDを指定します。
ここでも、AWS側ではマスターキーを使ってデータキーを復号するロジックを保持していますが、復号したデータキー自体は保存しません。
ユーザには、暗号化されたデータキーと、暗号化されていないデータキーが返却されます。
データの復号＠ローカル
データキーの復号によって手に入れた暗号化されていない鍵を使って、データを復号します。データを暗号化する時と同じく、これはローカルでの操作です。
データの復号に利用したデータキーは即座に捨てることが重要です。
マスターキーの有効化/無効化
マスターキーは、一時的に無効化したり、再び有効化したりすることができます。
マスターキーを無効化している間は、そのマスターキーを利用するすべてのAPIリクエストが失敗するようになります。マスターキー自身の更新はもちろん、データキーの生成、データキーの復号などもです。
ユーザ側では暗号化されたデータキーしか持っていないことが前提ですので、データキーが復号できないということは、データを復号できないということになります。マスターキーが無効化されている間は、そのマスターキーで生成したデータキーで暗号化したデータを復号できません。
マスターキーを有効化すると、そのマスターキーを使ったAPIリクエストが成功するようになります。
マスターキーのローテーション
マスターキーに対して、1年ごとのローテーションをするかしないかを設定できます。
マスターキーがローテーションされると、まず、新規に生成されたマスターキーがactiveというステータスになります。次に、既存のマスターキーが、deactivatedというステータスになります。
その時点からのすべてのリクエストは、新規に生成されたマスターキーに向けられます。しかし、例外として、以前のマスターキーを使って生成したデータキーからの復号のリクエストだけは、古いマスターキーに向けられます。
ローテーションされたマスターキーは、ただ復号のためだけに使えるというわけです。面白いですね。
マスターキーとデータキーの特徴
先ほどの比較表を再掲しておきます。
これまでの内容を踏まえると、マスターキーとデータキーのAWS内に永続化される/されない、外部にエクスポートできる/できないという違いが、ご理解いただけたかと思います。
鍵の権限管理
マスターキーを作成する時には、Key Policyを定義することができます。何も指定しないと、次のようなデフォルトのPolicyが紐づけられます。
Key Policyを工夫することで、マスターキーを管理する権限と、データキーを利用する権限を分離できます。
KMSの醍醐味はこの部分ではないでしょうか。KMSを利用の際には、権限の分離をぜひご検討ください。
おわりに
まとめです。
- 暗号化されたデータキーは、大事に保管しましょう
- なくすと、暗号化したデータを復号できなくなります
- 暗号化されていないデータキーは、暗号化/復号に使ったら、すぐに捨てましょう
- この作業をユーザが徹底することで、セキュリティが担保されます
- Key Policyを活用して、マスターキーの管理者とデータキーの利用者を分けましょう
今回は、KMSの概要をご説明しました。何かのお役に立てば幸いです。
それでは、また。
